A radio-frequency identification (RFID) system comprises readers, also known as interrogators, and tags, also known as labels or transponders. One or more RFID readers may communicate with one or more RFID tags in any numbers of ways. Some such ways are called protocols which call for specific manners of signaling between readers and tags. EPC UHF Gen2 Air Interface Protocol is a widely used protocol, which defines physical and logical requirements for a passive tag, in a case where a reader talks first, throughout the 860 to 960 MHz frequency range. The term “Gen2V2 protocol” will be used to refer to this protocol in the subsequent text.
According to the Gen2V2 protocol, readers manage a tag population within their effective read zone using three basic operations. Each of these operations may comprise multiple commands. The operations are defined as follows:                Select, to choose a tag population. The set of commands dedicated to the Select operation includes the Select command.        Inventory, to identify individual tags within the tag population. The set of commands dedicated to the Inventory operation includes Query, QueryAdjust, QueryRep, ACK and NAK commands.        Access, to communicate with an identified tag. The reader may perform a core operation such as reading, writing, locking, or killing the tag; a security-related operation such as authenticating the tag; or a file-related operation such as opening a particular file in the tag's memory. The set of commands dedicated to the Access operation includes, among others Req_RN and Authenticate commands.        
Readers support and tags provide 4 sessions, denoted S0, S1, S2 and S3. Tags participate in one and only one session during an inventory round, and two or more readers can use sessions to independently inventory a common tag population. Each tag comprises four flags denoted ‘inventoried flags’, each inventoried flag being associated with one of the four sessions. A tag shall maintain an independent inventoried flag for each of its four sessions, and each inventoried flag may have two values, either value A or value B.
Moreover, each tag has a slot counter and a state, which may be implemented all along the Select, Inventory and Access operations. A slot counter contains a value, said value being used to determine the point in an inventory round at which a tag may respond, as it will be explained later. A state characterizes the tag's behavior and response to a reader command. The tag state set includes Ready, Arbitrate, Reply, Acknowledged, Open, Secured and Killed.
Ready is a holding state for energized tags that are neither Killed nor currently participating in an Inventory round: upon entering an energizing radio-frequency (RF) field, a tag that is not killed shall enter the Ready state. A reader may first issue a Select command to select a population of tags in the Ready state. The Select command can set a tag's inventoried flag to either A or B in any one of the four sessions. In this case, the Select command comprises configuration parameters among which a session number and an inventoried flag value. The Select command also comprises selection criteria, which won't be detailed here. Upon receiving a Select command, each tag evaluates the selection criteria, and depending on the evaluation may set the inventoried flag of the session specified in the command to the value specified in the command.
Subsequently, a reader shall issue a Query command. Query initiates an Inventory round and decides which tags participate in the round. A Query command comprises a session number, an inventoried flag value, and an integer in the range (0, 15), denoted slot-count parameter Q. The slot-count parameter sets the number of slots in the inventory round. Upon receiving a Query command, tags with the matching inventoried flag value for the specified session shall draw a Q-bit random value from their random number generator or pseudo-random number generator, and load said value into their slot counter. Subsequently, a tag shall transition to the Arbitrate state and remain silent if the value in its slot counter is nonzero, or transition to the Reply state if the value in its slot counter is zero.
Arbitrate is a holding state for tags that are participating in the current inventory round and whose slot counters hold nonzero values. After issuing a Query command but receiving no response within a time T1 called ‘Immediate reply time’, the reader typically issues one or more QueryAdjust or QueryRep commands. A QueryAdjust command comprises the session number in the previous Query, but a higher or a smaller slot-count parameter Q. A tag in Arbitrate state shall adjust the value in its slot counter upon receiving a QueryAdjust corresponding to the inventory round currently in progress, then pick a new Q-bit number, and load it into its slot counter. Subsequently, the tag shall transition to the Reply state if said number is zero, or stay in the Arbitrate state if said number is nonzero. A QueryRep command comprises the session number of the previous Query without changing the slot-count parameter. In the Arbitrate state, the tag shall decrement by one the value in its slot counter every time it receives a QueryRep corresponding to the inventory round currently in progress, and it shall transition to the Reply state when the value in its slot counter reaches zero. It should be noted that a tag in the Acknowledged, Open, or Secured state that receives a QueryRep command whose session parameter matches the session parameter in the prior Query, and that is not in the middle of a Kill or an Access command sequence shall invert its inventoried flag (i.e. A→B or B→A, as appropriate) for the current session and transition to Ready.
Upon entering the Reply state, the tag shall backscatter a 16-bit random or pseudo-random number (called RN16). In response, the reader shall acknowledge the tag by echoing the tag's backscattered RN16. This shall be done by sending an ACK command comprising the RN16. Thus, if the tag receives an ACK command containing an identical RN16 (a valid ACK command), it shall transition to the Acknowledged state. Subsequently, the tag shall send an EPC code, stored in a part of its memory called ‘EPC memory’. The EPC code identifies the object to which the Tag is or will be attached. It should be noted that another ACK command comprising the RN16 may be sent again to the tag in said Acknowledged state, so as to receive the EPC code again. On the contrary, if the tag fails to receive an ACK command within a time T2 or receives an invalid ACK (that is to say an ACK command including a different RN16), then it shall return to the Arbitrate state.
Access always begins with a reader moving a tag from the Acknowledged state to either the Open or the Secured state by issuing a Req_RN command comprising said tag's RN16. If the tag in the Acknowledged state receives a Req_RN with a correct RN16, it shall generate, store and backscatter a new 16-bit random or pseudo-random number, denoted handle, and transition to the Open or Secured state. Subsequently, if the reader wants to ensure that only this tag is in the Open or Secured state, then it may issue an ACK command with said handle as a parameter. The tag that receives the ACK command with the correct handle shall reply by backscattering said handle and remain in its current state (Open or Secured, as appropriate), whereas those that receive an ACK command with an incorrect handle shall transition from the Open or Secured state to the Arbitrate state.
The choice of transitioning to the Open or to the Secured state when receiving a Req_RN command with a correct handle depends on the tag's access password, said access password being a value stored in a memory of the tag. It should be noted that a tag in the Open state may execute some commands only, whereas a tag in the Secured state with appropriate privileges may execute all commands. A tag in the Open state shall transition to the Secured state after a successful authentication. In order to initiate said authentication, a reader may issue an Authenticate command, said command comprising the tag's handle.
A reader and a tag can communicate indefinitely in the Open or Secured state, but the reader may end the communication at any time in order to identify and access other tags by issuing a QueryRep command. In this case, the tag shall transition from the Open or Secured state to the Ready state. The whole process ends when the reader has issued Q−1 QueryRep commands subsequent to a Query command, where Q is the slot-count parameter comprised in said Query command.
FIG. 1 shows a RFID system comprising two readers, Reader A and Reader B, and a Tag population comprising five Tags 1, 2, 3, 4, 5. Tags 1, 2 and 3 are in the effective read zone for Reader A, and Tags 3, 4 and 5 are in the effective read zone for Reader B. This means Tags 1, 2 and 3 can receive operating energy and commands, and backscatter responses from a RF field generated by Reader A, and Tags 3, 4 and 5 can receive operating energy and commands, and backscatter responses from a RF field generated by Reader B.
By way of example only, Table 1A illustrates an inventory and access sequence between Reader A and Tags 1, 2 and 3 according to the Gen2V2 protocol. First column relates to Reader A, and shows in particular commands that Reader A issues, and responses that Reader A receives during the communication sequence. Last column relates to the Tags, and in particular shows actions performed by a Tag in response to a command received from Reader A. The middle column shows messages directions: an arrow pointing right indicates a command from Reader A to at least a Tag; an arrow pointing left indicates a response from at least a tag to Reader A. The second column shows the communication slot, which starts from zero and is incremented by one every time Reader A issues a QueryRep command subsequently to a Query command. When the communication slot reaches Q−1, where Q is the slot-count parameter included in the Query command, the sequence ends. The fourth column shows timing requirements to be applied to a command or a reply.
Table 1B—resp. 1C, 1D—relates to Tag 1—resp. Tag 2, 3. For each table, first column shows the state of the Tag, second column shows the value in the slot counter of the Tag, third column shows the RN16 or the handle (in hexadecimal) generated by the random number generator or pseudo-random number generator of the Tag, fourth column shows the session used by the Tag to communicate with Reader A, and last column shows the inventoried flag value associated with said session.
In a step 1, Reader A generates an RF field. As a result, Tags 1, 2 and 3, which are in the read zone for Reader A, enter the Ready state. At this stage, for each of these Tags, the slot counter does not contain any value, no RN16 or handle has been generated yet, the session to be used with Reader A has not been defined yet, and the inventoried flag value is not applicable since the session is undefined.
In a step 2, Reader A issues a Select command, said command comprising a session number Sx and an inventoried flag value IFVx. In the described example, the session number Sx is S2 and the inventoried flag value IFVx is A. As a result, Tags 1, 2 and 3 set their inventoried flag value for session S2 to A.
In a step 3, Reader A issues a Query command, said command comprising a session number Sx, an inventoried flag value IFVx, and a slot-count parameter Q in the range (0, 15). In the described example, the session number Sx is S2, the inventoried flag value IFVx is A, and the slot-count parameter Q is 8. As a result, Tag 1, 2 and 3 enter the Arbitrate state, and generate a Q-bit number and a 16-bit number (RN16) using their random number generator or pseudo-random number generator. In the described example, the Q-bit number and the RN16 generated by Tag 1 are 1 and 1111; the Q-bit number and the RN16 generated by Tag 2 are 2 and 2222; and the Q-bit number and the RN16 generated by Tag 3 are 3 and 3333. The communication slot is set to zero.
In a step 4, Reader A waits for time T1 and does not receive any reply, since none of Tags 1, 2 or 3 has zero as a value in their slot counter.
In a step 5, Reader A issues a QueryRep command, said command comprising the session number of the previous Query command, that is to say S2. As a result, Tags 1, 2 and 3, whose slot counters hold nonzero values, decrement their slot counter. Moreover, since the value in Tag 1's slot counter turns zero, Tag 1 transitions to the Reply state. The communication slot is increased to one.
In a step 6, Tag 1 backscatters its RN16, said RN16 being received by Reader A.
In a step 7, Reader A acknowledges Tag 1 by echoing its RN16 within an ACK command. As a result, Tag 1 transitions to the Acknowledged state.
In a step 8, Tag 1 sends its EPC code, said EPC code being received by Reader A.
In a step 9, Reader A sends a Req_RN command comprising Tag 1's RN16, which makes Tag 1 transition to the Open or Secured state, depending on Tag 1's access password.
In a step 10, Tag 1 generates, stores and backscatters a new 16-bit random or pseudo-random number, the handle, said handle being received by Reader A. In the described example, the handle generated by Tag 1 is 6666.
In a step 11, Reader A sends an Authenticate command comprising Tag 1's handle. As a result, Tag 1 transitions to the Open state.
In a step 12, Tag 1 backscatters a crypto response, said crypto response being received by Reader A.
In a step 13, Reader A issues a QueryRep command so as to identify other Tags. Said command comprises the session number of the previous Query command, that is to say S2. As a result, Tag 1 inverts its inventoried flag (A→B) and transitions to the Ready state. Besides that, all Tags with inventoried flag value A for session S2 and whose slot counter holds a nonzero value, that is to say Tags 2 and 3, decrement their slot counter. Since the value in Tag 2's slot counter turns zero, Tag 2 transitions to the Reply state. The communication slot is increased to two.
In a step 14, Tag 2 backscatters its RN16, said RN16 being received by Reader A.
In a step 15, Reader A acknowledges Tag 2 by echoing its RN16 within an ACK command. As a result, Tag 2 transitions to the Acknowledged state.
In a step 16, Tag 2 sends its EPC code, said EPC code being received by Reader A.
In a step 17, Reader A sends a Req_RN command comprising Tag 2's RN16, which makes Tag 2 transition to the Open or Secured state, depending on Tag 2's access password.
In a step 18, Tag 2 generates, stores and backscatters a new 16-bit random or pseudo-random number, the handle, said handle being received by Reader A. In the described example, the handle generated by Tag 2 is 7777.
In a step 19, Reader A sends an Authenticate command comprising Tag 2's handle. As a result, Tag 2 transitions to the Open state.
In a step 20, Tag 2 backscatters a crypto response, said crypto response being received by Reader A.
In a step 21, Reader A issues a QueryRep command so as to identify other Tags. Said command comprises the session number of the previous Query command, that is to say S2. As a result, Tag 2 inverts its inventoried flag (A→B) and transitions to the Ready state. Besides that, all Tags with inventoried flag value A for session S2 and whose slot counter holds a nonzero value, that is to say Tag 3 only, decrement their slot counter. Since the value in Tag 3's slot counter turns zero, Tag 3 transitions to the Reply state. The communication slot is increased to three.
In a step 22, Tag 3 backscatters its RN16, said RN16 being received by Reader A.
In a step 23, Reader A acknowledges Tag 3 by echoing its RN16 within an ACK command. As a result, Tag 3 transitions to the Acknowledged state.
In a step 24, Tag 3 sends its EPC code, said EPC code being received by Reader A.
In a step 25, Reader A sends a Req_RN command comprising Tag 3's RN16, which makes Tag 3 transition to the Open or Secured state, depending on Tag 3's access password.
In a step 26, Tag 3 generates, stores and backscatters a new 16-bit random or pseudo-random number, the handle, said handle being received by Reader A. In the described example, the handle generated by Tag 3 is 8888.
In a step 27, Reader A sends an Authenticate command comprising Tag 3's handle. As a result, Tag 3 transitions to the Open state.
In a step 28, Tag 3 backscatters a crypto response, said crypto response being received by Reader A.
In a step 29, Reader A issues a QueryRep command so as to identify other Tags. Said command comprises the session number of the previous Query command, that is to say S2. As a result, Tag 3 inverts its inventoried flag (A→B) and transitions to the Ready state. Nothing else happens since there are no more tags in Reader A's read zone that have A as an inventoried flag value for session S2. The communication slot is increased to four.
In a step 30, Reader A waits for time T1 and does not receive any reply to the previous QueryRep command.
In a step 31, Reader A issues another QueryRep comprising the session number of the previous Query command, that is to say S2. Nothing happens since there are no more tags in Reader A's read zone that have A as an inventoried flag value for session S2. The communication slot is increased to five.
In a step 32, Reader A waits for time T1 and does not receive any reply to the previous QueryRep command.
In a step 33, Reader A issues another QueryRep comprising the session number of the previous Query command, that is to say S2. Nothing happens since there are no more tags in Reader A's read zone that have A as an inventoried flag value for session S2. The communication slot is increased to six.
In a step 34, Reader A waits for time T1 and does not receive any reply to the previous QueryRep command.
In a step 35, Reader A issues another QueryRep comprising the session number of the previous Query command, that is to say S2. Nothing happens since there are no more tags in Reader A's read zone that have A as an inventoried flag value for session S2. The communication slot is increased to seven.
In a step 36, Reader A waits for time T1 and does not receive any reply to the previous QueryRep command. Since the slot-count parameter is 8 and the communication slot has reached 7, the inventory round is ended after this last unsuccessful attempt to identify other Tags.
As already explained, all ACK commands issued by a reader and intended for a tag shall include a 16-bit random number previously generated and backscattered by the tag, said number being either the RN16 or the handle. If a reader issues an ACK command to a tag in the Reply or Acknowledged state, then the echoed number shall be the RN16 that the tag previously backscattered as it transitioned from the Arbitrate state to the Reply state. If the reader issues an ACK command to a tag in the Open or Secured state, then the echoed number shall be the tag's handle. For reasons of convenience, the echoed 16-bit random number (either the RN16 or the handle) included in an ACK command is referred to as ‘session handle’. As a consequence, ‘session handle’ may refer indifferently to a tag's RN16 or handle. Upon receiving an ACK command, a tag shall verify that the session handle is correct prior to executing said command.
Receiving an ACK command with an incorrect session handle may happen in a RFID system having multiple RFID readers operating in parallel, because some tags might be simultaneously within the effective read zone for more than one reader, whether this is intentional or not. For instance, in the example illustrated in FIG. 1, Tag 3 is in the effective read zone for both Readers A and B. Thus, Tag 3 may hear an ACK command issued by Reader B while being in communication with Reader A. Said ACK command may for instance be intended for Tag 4. The probability of two readers simultaneously communicating with two tags which have the same session handle being 1 in 216, the session handle included in said ACK command is likely to be different from Tag 3's session handle.
A tag hearing an ACK command with an incorrect session handle shall not execute said command. Furthermore, as already mentioned, if said tag state is Open or Secured, then the tag shall transition to the Arbitrate state. This is problematic because a transition to the Arbitrate state essentially terminates communication between the tag and the reader with which the tag was communicating. In the previous-mentioned example, if Tag 3 is in the Open or the Secured state and hears Reader B sending an ACK command intended to Tag 4, said ACK command comprising Tag 4's session handle, then Tag 3 shall transition to the Arbitrate state, thereby losing connection with Reader A.
If a tag terminates communication with a reader, there is usually the possibility to identify and access said tag at a later time. However, this is not always the case when the tag is moving rapidly through read zones.